home *** CD-ROM | disk | FTP | other *** search
-
- Network Working Group J. Postel
- Request for Comments: 856 J. Reynolds
- ISI
- Obsoletes: NIC 15389 May 1983
-
- TELNET BINARY TRANSMISSION
-
-
- This RFC specifies a standard for the ARPA Internet community. Hosts on
- the ARPA Internet are expected to adopt and implement this standard.
-
- 1. Command Name and Code
-
- TRANSMIT-BINARY 0
-
- 2. Command Meanings
-
- IAC WILL TRANSMIT-BINARY
-
- The sender of this command REQUESTS permission to begin
- transmitting, or confirms that it will now begin transmitting
- characters which are to be interpreted as 8 bits of binary data by
- the receiver of the data.
-
- IAC WON'T TRANSMIT-BINARY
-
- If the connection is already being operated in binary transmission
- mode, the sender of this command DEMANDS to begin transmitting
- data characters which are to be interpreted as standard NVT ASCII
- characters by the receiver of the data. If the connection is not
- already being operated in binary transmission mode, the sender of
- this command REFUSES to begin transmitting characters which are to
- be interpreted as binary characters by the receiver of the data
- (i.e., the sender of the data demands to continue transmitting
- characters in its present mode).
-
- A connection is being operated in binary transmission mode only
- when one party has requested it and the other has acknowledged it.
-
- IAC DO TRANSMIT-BINARY
-
- The sender of this command REQUESTS that the sender of the data
- start transmitting, or confirms that the sender of data is
- expected to transmit, characters which are to be interpreted as 8
- bits of binary data (i.e., by the party sending this command).
-
- IAC DON'T TRANSMIT-BINARY
-
- If the connection is already being operated in binary transmission
- mode, the sender of this command DEMANDS that the sender of the
- data start transmitting characters which are to be interpreted as
-
-
- Postel & Reynolds [Page 1]
-
-
-
- RFC 856 May 1983
-
-
- standard NVT ASCII characters by the receiver of the data (i.e.,
- the party sending this command). If the connection is not already
- being operated in binary transmission mode, the sender of this
- command DEMANDS that the sender of data continue transmitting
- characters which are to be interpreted in the present mode.
-
- A connection is being operated in binary transmission mode only
- when one party has requested it and the other has acknowledged it.
-
- 3. Default
-
- WON'T TRANSMIT-BINARY
-
- DON'T TRANSMIT-BINARY
-
- The connection is not operated in binary mode.
-
- 4. Motivation for the Option
-
- It is sometimes useful to have available a binary transmission path
- within TELNET without having to utilize one of the more efficient,
- higher level protocols providing binary transmission (such as the
- File Transfer Protocol). The use of the IAC prefix within the basic
- TELNET protocol provides the option of binary transmission in a
- natural way, requiring only the addition of a mechanism by which the
- parties involved can agree to INTERPRET the characters transmitted
- over a TELNET connection as binary data.
-
- 5. Description of the Option
-
- With the binary transmission option in effect, the receiver should
- interpret characters received from the transmitter which are not
- preceded with IAC as 8 bit binary data, with the exception of IAC
- followed by IAC which stands for the 8 bit binary data with the
- decimal value 255. IAC followed by an effective TELNET command (plus
- any additional characters required to complete the command) is still
- the command even with the binary transmission option in effect. IAC
- followed by a character which is not a defined TELNET command has the
- same meaning as IAC followed by NOP, although an IAC followed by an
- undefined command should not normally be sent in this mode.
-
- 6. Implementation Suggestions
-
- It is foreseen that implementations of the binary transmission option
- will choose to refuse some other options (such as the EBCDIC
- transmission option) while the binary transmission option is in
-
-
-
-
- Postel & Reynolds [Page 2]
-
-
-
- RFC 856 May 1983
-
-
- effect. However, if a pair of hosts can understand being in binary
- transmission mode simultaneous with being in, for example, echo mode,
- then it is all right if they negotiate that combination.
-
- It should be mentioned that the meanings of WON'T and DON'T are
- dependent upon whether the connection is presently being operated in
- binary mode or not. Consider a connection operating in, say, EBCDIC
- mode which involves a system which has chosen not to implement any
- knowledge of the binary command. If this system were to receive a DO
- TRANSMIT-BINARY, it would not recognize the TRANSMIT-BINARY option
- and therefore would return a WON'T TRANSMIT-BINARY. If the default
- for the WON'T TRANSMIT-BINARY were always NVT ASCII, the sender of
- the DO TRANSMIT-BINARY would expect the recipient to have switched to
- NVT ASCII, whereas the receiver of the DO TRANSMIT-BINARY would not
- make this interpretation.
-
- Thus, we have the rule that when a connection is not presently
- operating in binary mode, the default (i.e., the interpretation of
- WON'T and DON'T) is to continue operating in the current mode,
- whether that is NVT ASCII, EBCDIC, or some other mode. This rule,
- however, is not applied once a connection is operating in a binary
- mode (as agreed to by both ends); this would require each end of the
- connection to maintain a stack, containing all of the encoding-method
- transitions which had previously occurred on the connection, in order
- to properly interpret a WON'T or DON'T. Thus, a WON'T or DON'T
- received after the connection is operating in binary mode causes the
- encoding method to revert to NVT ASCII.
-
- It should be remembered that a TELNET connection is a two way
- communication channel. The binary transmission mode must be
- negotiated separately for each direction of data flow, if that is
- desired.
-
- Implementation of the binary transmission option, as is the case with
- implementations of all other TELNET options, must follow the loop
- preventing rules given in the General Considerations section of the
- TELNET Protocol Specification.
-
- Consider now some issues of binary transmission both to and from
- both a process and a terminal:
-
- a. Binary transmission from a terminal.
-
- The implementer of the binary transmission option should
- consider how (or whether) a terminal transmitting over a TELNET
- connection with binary transmission in effect is allowed to
- generate all eight bit characters, ignoring parity
- considerations, etc., on input from the terminal.
-
-
- Postel & Reynolds [Page 3]
-
-
-
- RFC 856 May 1983
-
-
- b. Binary transmission to a process.
-
- The implementer of the binary transmission option should
- consider how (or whether) all characters are passed to a
- process receiving over a connection with binary transmission in
- effect. As an example of the possible problem, TOPS-20
- intercepts certain characters (e.g., ETX, the terminal
- control-C) at monitor level and does not pass them to the
- process.
-
- c. Binary transmission from a process.
-
- The implementer of the binary transmission option should
- consider how (or whether) a process transmitting over a
- connection with binary transmission in effect is allowed to
- send all eight bit characters with no characters intercepted by
- the monitor and changed to other characters. An example of
- such a conversion may be found in the TOPS-20 system where
- certain non-printing characters are normally converted to a
- Circumflex (up-arrow) followed by a printing character.
-
- d. Binary transmission to a terminal.
-
- The implementer of the binary transmission option should
- consider how (or whether) all characters received over a
- connection with binary transmission in effect are sent to a
- local terminal. At issue may be the addition of timing
- characters normally inserted locally, parity calculations, and
- any normal code conversion.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Postel & Reynolds [Page 4]
-
-